The HiPerCops IDE has many components. There are features that facilitate system design, perform device layout, simulate faults, execute programs, and assist in output analysis. From the highest level of abstraction, though, the application can be viewed as a simple process. Like any other piece of software, the IDE takes a set of inputs, executes instructions on the data, and produces a result. The IDE is described using a top-down approach, starting at that high level of abstraction and systematically delving into the details of each component.

\section{Application Context}

\begin{figure}
\centering
\includegraphics[scale=0.3]{img/dfd_context}
\caption{DFD context}
\label{fig:DfdContext}
\end{figure}

The basic concept of the HiPerCopS IDE is to draw data from two or three sources of input and produce a single output. This is shown as a data-flow diagram (DFD) \cite{yourdon_book89} in Figure \ref{fig:DfdContext}. The three input sources include a system concept, a set of input data, and, optionally, a fault model. The IDE returns the outputs of the system as its result.

A system concept is a general idea to be implemented on the targeted medium-grain reconfigurable hardware device. This system could be as simple as a small adder, or as complex as an entire DSP consisting of many units. In any case, a detailed design is not required as a prerequisite for using the IDE. The application provides all of the necessary tools and support for transforming an abstract concept into a complete system design, regardless of the scope of the problem domain.

In order to test a system design, the user must supply a set of data inputs to the simulator. The HiPerCopS IDE accepts a list in comma-separated value (CSV) format, arranged in columns and rows. The first row of the input file consists of system input labels, allowing each column to be mapped to a specific system input label. An $n$-input system will have $n$ columns, with the first row containing $n$ unique labels. The number of rows is arbitrary, but each column must have the same number of rows.

The fault model is an optional argument to the HiPerCopS IDE. It should be included when the user wants to test their system's robustness and ability to operate in the presence of hard faults. Faults can be generated randomly, specified explicitly, or a combination of the two. Random faults are distributed automatically by the IDE, with the user indicating the number of faults to be placed. Faults with explicit locations are listed in CSV format, with one fault entry per row. Fault entries have the following format, and the entry parameters are explained in Table \ref{tab:faultentryparams}:

\begin{table}[t]
\centering
\begin{tabular}{|l|l|}
\hline
Parameter & Description \\
\hline \hline
dev\_r & row index in the device cellfield \\
\hline
dev\_c & column index in the device cellfield \\
\hline
cell\_r & row index in the cell's element array \\
\hline
cell\_c & column index in the cell's element array \\
\hline
elem\_r & row index in the element's LUT \\
\hline
elem\_c & column index in the element's LUT \\
\hline
v & stuck-at value (either 0 or 1) \\
\hline
\end{tabular}
\caption{Fault entry parameters (indexes are zero-based)}
\label{tab:faultentryparams}
\end{table}

\begin{verbatim}
<dev_r>,<dev_c>,<cell_r>,<cell_c>,<elem_r>,<elem_c>,<v>
\end{verbatim}

The output of the application represents the results calculated by the system when the inputs are applied. The output file has the same format as the input file: CSV entries arranged in columns and rows, with the system output labels listed in the top row.

\section{Graphical and Command-line Interfaces}

\begin{figure}
\centering
\includegraphics[scale=0.2]{img/dfd_0}
\caption{DFD 0 - HiPerCopS IDE}
\label{fig:Dfd0}
\end{figure}

The HiPerCopS IDE consists of two major components, the graphical user interface (GUI) and the command-line interface (CLI) (Figure \ref{fig:Dfd0}). These two components work together to present the user with a unified application framework, and each is responsible for a specific set of functionality.

\subsection{The Graphical User Interface}

\begin{figure}
\centering
\includegraphics[scale=0.3]{img/dfd_1}
\caption{DFD 1 - Graphical User Interface}
\label{fig:Dfd1}
\end{figure}

The GUI component is the portion of the application which interacts directly with the user. As shown in Figure \ref{fig:Dfd1}, it is used to manage user inputs and facilitate system design. It also displays results, error messages, and other feedback to the user. Essentially, the GUI provides an easy-to-use interface to the functionality of the CLI.

{\bf System Design.} The system design process involves transforming an abstract system concept into a well-defined system description. The system description contains information on the required modules and how those modules are interconnected. The HiPerCopS IDE provides users with the ability to draw their system concepts as directed graphs, using nodes to represent modules and connectors to indicate data flow. After the system concept is drawn, the IDE uses the graph to generate a text-based representation of the system. The resulting text file represents the system definition, and it is formatted according to a formal programming language grammar. This format is so simple to read and understand that users may choose to write their system definitions directly, bypassing the graphing tool provided by the HiPerCopS IDE.

{\bf Fault Generation.} As described before, the HiPerCopS IDE has the ability to generate random faults and inject faults at specified locations. The fault generation process is performed in the GUI portion of the IDE. To generate random faults, users can select a predetermined number of faults from the application menu or enter a different number using a dialog box. Explicitly located faults have to be listed in fault files, which are handled in the file selection process.

{\bf File Selection.} The file selection process involves the standard file browser paradigm. Users will be familiar with this interface, so they will have no trouble with finding and selecting their input data files and fault files. Currently, these files must be generated outside of the IDE using text processor or spreadsheet editor. In the future, the HiPerCopS IDE will support creating and editing of these files.

{\bf Mapping Options.} In the GUI portion of the HiPerCopS IDE, the user must choose a specific algorithm for mapping system modules to the target device. There are a number of mapping options available, and they are selected using the application menu. The mapping process and the algorithms involved will be discussed in depth in Chapter Five.

\subsection{The Command-line Interface}

\begin{figure}
\centering
\includegraphics[scale=0.3]{img/dfd_2}
\caption{DFD 2 - Command-line Interface}
\label{fig:Dfd2}
\end{figure}

{\bf Device Preparation.} The device preparation task takes a formal system description and implements the modules as a set of software class structure instantiations. This is a fully automated process that requires no input or oversight from the user. Since the member modules of a system can be quite diverse, device preparation relies on a set of libraries for implementation details. There is one library each for elements, cells, modules, and systems. These libraries are covered in more depth in Chapter Six.

The process of device preparation also involves handling the fault model. During this stage, the device is instantiated as a software object. The specified fault locations are then found on the device, and that particular location is marked as a ``stuck-at" fault. This means that the bit at the specified location will always be stuck at a logic high or a logic low level, unable to change during a reconfiguration or memory operation. Faults of this nature have the potential to cause undesired behavior during a simulation.

{\bf Mapping.} Once the device is created, the faults are implemented, and the modules are established, the next step involves mapping the modules to the device. Since the HiPerCopS architecture is reconfigurable, systems can be mapped in a number of different ways and still produce the same behavior. As long as the modules are connected correctly via local and H-tree interconnections, mappings are very flexible. In order to take advantage of this feature, a number of different mapping strategies have been developed. These algorithms, fully described in Chapter Five, are optimized for different scenarios. For instance, one method minimizes the amount of device area required while another method avoids mapping modules to faulty areas. The user has the ability to select a particular mapping strategy, but the process itself is fully automated.

{\bf Input Processing.} Input processing involves parsing the CSV file, normalizing the data, and applying each input entry to the correct system input module. Parsing is a simple task since the format of the file is a well-defined standard. To normalize the data and ensure that it can be processed by the system modules, the HiPerCopS IDE pads each binary string to the necessary length. For each processing interval, a new set of inputs, representing one row of the input file, are applied to the system. This is possible due to the pipelined nature of the HiPerCopS architecture.

{\bf Execution.} To perform the execution of a system, the inputs are propagated from the modules to the cells and down to the elements. The elements perform their look-up operations, and the results are passed back up to the cells. The cells exchange data with each other and continue the processing loop until the module delays have been exhausted. At this point, the modules use the H-tree global interconnect network to exchange data at the module level. System execution is complete when the last set of inputs has traveled through the entire set of system modules and the results have been produced at the end of the pipeline.

{\bf Output Generation.} The output generation process consists of gathering the results of the system execution, writing them to a CSV file, sending a copy to the GUI display, and performing analysis. The output file shares the same format as the input file, making it easy to understand from a user standpoint and easy to manipulate using common software tools. The HiPerCopS IDE provides a feature that allows users to compare the output file with a set of expected results, highlighting the differences between the two. This can be especially useful when running tests or debugging a particular system implementation.

The CLI component could be used on its own without any interaction with the GUI. To do this, decisions made in the GUI are passed as command-line arguments. This might be desirable in some circumstances, including automated testing or long-running simulations. However, since a major goal of the HiPerCopS IDE is to be user-friendly, the GUI is really an essential feature. The GUI and the CLI were designed to be separate entities, though, to give users the option of command-line-only operation.

\section{Recursive Composition}

\begin{figure}
\centering
\includegraphics[scale=0.2]{img/recursive_composition}
\caption{Recursive composition in the HiPerCopS IDE}
\label{fig:RecursiveComposition}
\end{figure}

The software structure of the HiPerCopS IDE mimics the recursive composition of the HiPerCopS architecture. Cells are composed of elements, modules are composed of cells, systems are composed of modules, and devices are composed of systems. Figure \ref{fig:RecursiveComposition} shows this concept, and adds another relationship: platforms are composed of devices. This is a future enhancement, not yet implemented in the IDE, that will allow for multi-core implementations of the architecture.

The class structure of the IDE is a faithful representation of the physical architecture. These objects are created during the device preparation step, process 2.1 of the DFD (Figure \ref{fig:Dfd2}). Inspection of the source code reveals the implementation details of the HiPerCopS IDE and the HiPerCopS architecture simultaneously. The following class documentation, then, will be beneficial to both users of the simulator and designers of reconfigurable hardware.

\subsection{The Element Class}

\begin{figure}
\centering
\includegraphics[scale=0.35]{img/element_uml}
\caption{UML representation of the Element class}
\label{fig:ElementUml}
\end{figure}

The element is the basic building block of the HiPerCopS architecture. It also serves as the atomic structure for the HiPerCopS IDE (Figure \ref{fig:ElementUml}). 

\subsubsection{Attributes}
\begin{quote}
{\bf type.} This string is used to describe which look-up table is implemented in the element. The name contained in this variable must match one of the entries in the element library. The type attribute can be ignored when the element is in memory mode.

{\bf element.} This array is a 16x2 matrix of bits. In memory mode, this attribute is responsible for holding the stored values, reading from them and writing to them when required. In math mode, the array acts as a LUT that can be used to perform computations.
\end{quote}

\subsubsection{Operations}
\begin{quote}
{\bf \_\_init\_\_().} This constructor initializes the element member variables. In memory mode, the bits of the element array are set to zero. In math mode, the type attribute is used to initialize the LUT with values from the element library.

{\bf set\_type().} The type of the element can be changed with this operation. The element's type attribute is changed to the value passed into the function, and the element's LUT is modified using values from the element library.

{\bf lut().} The lut method takes a row address as its input, finds the corresponding entry in the element array, and returns the result. This is the basic math mode operation performed by the element class, and this simple function forms the basis for more complex operations at the cell and module levels.

{\bf read().} The read method is used when the element is in memory mode. It takes row and column indexes as its input and uses that information to address the element array. The bit found at that location is returned as a string, either `1' or `0'.

{\bf write().} The write function takes three inputs: a row index, a column index and a bit value. The row and column parameters are used to address the element array, and the bit value is written to that location. The write operation is used when the element is in memory mode.
\end{quote}

\subsection{The Interconnect Class}

\begin{figure}
\centering
\includegraphics[scale=0.25]{img/interconnect_network}
\caption{Example of a partial interconnect network}
\label{fig:InterconnectNetwork}
\end{figure}

\begin{figure}
\centering
\includegraphics[scale=0.35]{img/interconnect_uml}
\caption{UML representation of the Interconnect class}
\label{fig:InterconnectUml}
\end{figure}

The interconnect class provides a medium for communication within cells or cellfields. Each entry in the interconnect network represents a local bus in the physical hardware. Inside a cell, communication busses connect each element to its eight closest neighbors (Figure \ref{fig:InterconnectNetwork}). Cells are connected in the same way as members of a cellfield. Essentially, interconnect networks provide intermediate data storage for the object arrays they support.

\subsubsection{Attributes}
\begin{quote}
{\bf network.} The network is an array of interconnect entries. Each interconnect entry can store a single string of binary data, meant to represent the output of an element or cell and, subsequently, the input of another element or cell.
\end{quote}

\subsubsection{Operations}
\begin{quote}
{\bf \_\_init\_\_().} Given a target array of cells or elements, the initializer creates an interconnect network of the correct size. For an $m \times n$ array of elements or cells, the interconnect network will have $(2 \ast m + 1) \times (2 \ast n + 1)$ entries.

{\bf find\_entry().} Element and cell arrays are addressed using row and column indexes, but the interconnect network has different dimensions. In order to work with the interconnect entries surrounding a specific element or row, an index conversion must be performed. This function takes an element or cell address along with the particular bus in question. The eight busses attached to each cell or element are referred to as `nw', `n', `ne', `e', `se', `s', `sw', and `w'. The function returns the row and column indexes for the corresponding entry in the interconnect network.

{\bf set().} The set function is used to place a binary string value into the interconnect network. As arguments, it takes the row/column address of the element or cell, the name of the bus to be written to, and the value to be written. The row/column address is translated to an interconnect address by the find\_entry utility, allowing cell or cellfield operations to proceed without any implementation details regarding the interconnect network.

{\bf get().} Binary string values can be read from the interconnect network entries using the get function. Like the set function, get accepts a row/column address and a bus name. The binary string value stored in that interconnect entry is returned.
\end{quote}

\subsection{The Cell Class}

\begin{figure}
\centering
\includegraphics[scale=0.35]{img/cell_uml}
\caption{UML representation of the Cell class}
\label{fig:CellUml}
\end{figure}

Cell objects are responsible for performing all of the computations in a system. Since this is the case, the cell class contains a number of utilities that facilitate math mode functionality (Figure \ref{fig:CellUml}).

\subsubsection{Attributes}
\begin{quote}
{\bf matrix.} The matrix is an array of elements, arranged in 4 rows and 4 columns. This follows the conventions set in the HiPerCopS architecture.

{\bf interconnect.} The interconnect attribute is an instance of the interconnect class. It allows elements in the matrix to communicate with each other.

{\bf type.} The cell type is a string that corresponds to a particular file name in the cell library. This associated library file indicates the types and positions of the elements in the matrix.
\end{quote}

\subsubsection{Operations}
\begin{quote}
{\bf \_\_init\_\_().} The cell initializer creates the cell matrix and sets the element LUTs according to the cell type.

{\bf set\_type().} This function can be used to set or change the cell's type. It is useful during initial device setup or system reconfiguration.

{\bf get\_type().} The get\_type utility simply returns the current cell type. It is used by the GUI portion of the IDE to display a graphical representation of the cell.

{\bf compute().} The compute function takes a set of binary input strings, processes them using the elements in the cell's matrix, and returns the resulting binary output string. It uses init\_inputs, propogation\_delay, and get\_result as helper functions.

{\bf init\_inputs().} To seed the cell's interconnect network with the proper inputs, the compute function calls init\_inputs. This function splits each binary input string and applies the resulting substrings to the appropriate interconnect entries. Then the elements process these inputs using their LUTs, and the data is propogated through the cell.

{\bf propogation\_delay().} Cell computations run in a loop, allowing the elements to continue processing data contained in the interconnect network until the computation has completed. The amount of time necessary for inter-element propogation to complete depends on the dimensions of the cell. This propogation delay is a constant value for the HiPerCopS architecture, but it could be a variable quantity for other MGRH architectures. In order to make the HiPerCopS IDE as flexible as possible, the propogation delay is explicitly calculated for each cell.

{\bf get\_result().} After the matrix elements have completed their computations and the binary input strings have propogated through the entire cell, the get\_result function gathers the output substrings from the interconnect network. These substrings are concatenated together and returned as a single output.
\end{quote}

\subsection{The Cellfield Class}

\begin{figure}
\centering
\includegraphics[scale=0.35]{img/cellfield_uml}
\caption{UML representation of the Cellfield class}
\label{fig:CellfieldUml}
\end{figure}

Cellfields are groups of related cells. In the HiPerCopS IDE, the cellfield class acts as a base class for modules and devices. It only provides general attributes and operations, leaving most implementation details up to its derived classes.

\subsubsection{Attributes}
\begin{quote}
{\bf width.} Cellfields are arranged in rectangular arrays. The width attribute simply indicates the number of cells in each row of the cellfield. 

{\bf height.} The height attribute holds the integer value representing the number of rows in the cellfield.

{\bf interconnect.} The cells of a cellfield must interact with one another, and the interconnect attribute is an interconnect object that facilitates inter-cell communication.

{\bf cellfield.} The cellfield is an array of cell objects.
\end{quote}

\subsubsection{Operations}
\begin{quote}
{\bf \_\_init\_\_().} The cellfield initialization function defines the cellfield array according to the cellfield type described in the cellfield library. It also assigns values to its height and width member attributes.

{\bf set\_type().} Each cellfield has a type that corresponds to a particular file in the cellfield library. This library file specifies the types and positions of the cells in the cellfield array, as well as the local networking rules to be observed by the interconnect network.
\end{quote}

